home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
misc
/
merit
/
noop
/
papers
/
idrp4ip
< prev
next >
Wrap
Text File
|
1992-03-14
|
33KB
|
1,021 lines
DRAFT RFC - IDRP for IP
(edit version 1)
Susan Hares
March 14, 1991
Author: Susan Hares
1.) Status
This memo specifies the additions to ISO Inter-Domain Routing
Protocol (DIS ballot 10747)[1] to enable it to be used as an
Inter-Autonomous routing protocol in TCP/IP Internet. The IDRP
plus these additions which can support Inter-Autonomous Routing
protocols in the TCP/IP Internet will be called "IDRP for IP" in
this document. Dual IDRP, that is IDRP that support can Inter-
Domain/Inter-Autonomous routing in TCP/IP and OSI Internet will
be discussed in RFCxxx[2]. The whole family of IDRP related
documents and their function are list in RFCxxx "IDRP Document
family tree"[3].
2.) Abstract
IDRP is defined in the ISO document (DIS ballot 10747) as the
protocol for exchange of Inter-Domain routing information
between routers to support forwarding of ISO 8473 PDUs
(Connectionless Network Layer Protocol (CLNP))[4]. This document
contains the appropriate modification to the IDRP protocol
definition that enables it to be used as protocol for exchange
inter-autonomous system information among routers to support
forwarding of IP packets.
Structure of Document:
3 - Introduction
4 - Carrying IDRP packets over IP
5 - Implementor's profile
- 5.1) Function of IDRP protocol which may not
be implemented for IDRP for IP
- 5.2) IDRP functions to forward IP packets
- 5.3) Domain Configuration Information Required
for IDRP for IP
- 5.4) Advertising NLRI information for IP addresses
6 - IP Address information in UPDATE PDU
7 - RDIs in UPDATE PDU
8 - Deployment Guidelines for IDRP for IP
- 8.1) Minimum configuration of an AS/RD.
- 8.2) 1 IP prefix per routing domain
- 8.3) Two BIS-BIS sessions between the same routers
9 - References
3.) Introduction
The Inter-domain routing protocol IDRP or formally
DRAFT RFC - IDRP for IP March 14, 1991
"The Protocol for the Exchange of Inter-Domain Routeing
information among Intermediate Systems to support
Forwarding of ISO 8473 PDUs (IDRP) [DIS ballot 10747]"
is the process of being defined for the Connectionless Network
Layer protocol (CLNP) [ISO 8473]. This ISO protocol does not
require participating domains to support any specific ISO Intra-
Domain protocol like IS-IS (ISO IS 10589)[5]. The IDRP protocol
does not require participating routes to run ES-IS (ISO 9542)[6].
The only requirement imposed by the protocol is that the protocol
information can be exchange between participating routers over
connectionless network layer which in the case of OSI is CLNP.
IDRP does not place any restrictions on the structure of
reachability information as long it can be expressed as
arbitrary variable length prefixes. Because of this, IDRP can be
easily adapted to pass as Inter-Autonomous routing protocol which
can be used in the pure TCP/IP Internet.
This document assumes that the reader is familiar with the
following documents:
- IP protocol specification (RFC 791)[7], and
- IDRP specification (CD/DIS 10747).
A few term definitions are in order to aid the reader:
BIS - a border Intermediate System (or border router)
IS - Intermediate system (router)
PDU - packet
NPDU - an IP packet
BISPDU - an IDRP message exchange between a pair of BISs
FIB (Forwarding Information Base) - IP forwarding Table
While conceptual it is possible to define map the TOS field and
security field into IDRP QOS NPDU-derived Distinguishing
Attributes, this mapping is outside the scope of this document.
The use of the following IDRP distinguishing Attribute attributes
for IP packets will not be defined in this document:
- TRANSIT Delay
- Residual Error
- Expense
- Source Specific QOS
- Destination Specific QOS
3
DRAFT RFC - IDRP for IP March 14, 1991
- Source Specific Security QOS
- Destination Specific Security QOS.
Both the mapping of the IP packet's TOS and security fields will
be discussed in the RFC xxxxxx - IP TOS, Security and IDRP for
IP[8].
4) BISPDUs in IP protocol
BISPDUs are carried directly over IP as NPDUs with a protocol id
of xxxx.
5) Implementors Guide for IP specific functions.
In order to implement IDRP for IP only a subset of the features
of the IDRP protocol must be implemented. The functions of the
IDRP protocol which may not to be implemented for IDRP for IP are
those functions which deal with:
- forwarding the CLNP packets,
- the interface to CLNP (ISO 8473), and
- support of the Network Management
information described in the IDRP GDMO.
Section 5.1 describes which IDRP functions may not be implement
in terms of sections of the DIS Ballot IDRP (10747) document.
NLRI information passed by the UPDATE PDU has a Type field which
indicates the protocol family for the NLRI information. The BIS
supporting IDRP for IP may ignore any NLRI information with a
type field that does not have a IP NLPID. The BIS supporting
IDRP for IP must support the processing of any NLRI information
with a IP NLPID.
The NEXT_HOP attribute in the UPDATE PDU also has a Type field
which indicates which protocol family for the NET of the
NEXT_HOP. The BIS supporting IDRP for IP may ignore any NEXT_HOP
information with a CLNP NLPID, The BIS supporting IDRP for IP
must support the processing of any NEXT_HOP attribute with the IP
NLPID.
A BIS for IDRP for IP must implement:
1.) an interface to the IP protocol described in section 4,
2.) IP packet forwarding functions described in section 5.2,
3.) Domain Configuration Information listed in section 5.3,
and
4
DRAFT RFC - IDRP for IP March 14, 1991
4.) Advertisement of IP address in NLRI information as
described in section 5.4.
Descriptions of IDRP features are given both in both text
descriptions and in the ISO PICS (A Protocol Implementation
Conformance Statement (PICS) format.
5.1) Features in IDRP Protocol Which Many not be implemented
Description
------------
For IDRP for IP over IP only, the following items dealing with
CLNP in the IDRP conformance (section 13.1) do not have to be
implemented:
r.) forwarding ISO 8473 NPDU's according to section 9
(of IDRP document)
s.) supporting the interface to ISO 8473 using service
primitives in section 10 (IDRP document)
t.) provided the managed objects described in section 12
(IDRP MIB replaces the ISO GDMO section.)
(Note: If Dual IDRP is implemented, this features do have be
implemented.)
PICS Table Information
-----------------------
The following tables of function in the IDRP DIS Ballot (10747)
IDRP PICS, may not be implemented for IDRP for IP: Table A.4.8 -
IDRP CLNS Forwarding. Item "BISMGT" in Table A.4.3 - IDRP
General which specifies ISO Network Management support does not
have to be implemented.
5.2) IDRP for IP forwarding of IP packets
This section is intended to define the same function for IP
packets as is defined for CLNP packets in the "Forwarding Process
for CLNS (Section 9) of the IDRP DIS Ballot document". However,
at this time the IDRP for IP document does not contain any
specification of the TOS-> NPDU-derived Distinguishing
attributes. Therefore, any references to the Adj-Ribs or FIBs
for Distinguishing attributes other than the "default" attribute
have been excluded from this section. The specification of the
interaction between the IP packets TOS, security and IDRP for IP
is outside this specification. (RFC xxx IP TOS, Security and
5
DRAFT RFC - IDRP for IP March 14, 1991
IDRP for IP[8]).
After a BIS's determines the packets destination IP address, the
BIS shall proceed as follows:
a.) if the destination system is located in its own RD,
AND the destination address depicts a system located
within the Routing domain then the BIS shall forward
the IP packet to any of the ISs listed in the managed
object INTRA-IS. That, is any further forwarding of
the IP packet is the responsibility of the IP intra-domain
(intra-autonomous system) routing protocol.
b.) if the destination system is located in a different RD,
the local BIS shall perform the following actions:
The incoming IP packet shall be forward based on the
longest IP address prefix that matches the destination
of the incoming IP packet, as follows:
1.) If the entry in the inter-domain FIB that
corresponds to the destination address of an
incoming IP packet contains a NEXT_HOP t h a t
identifies an IS that shares one or more common IP
subnet with the local BIS, then the IP packet
shall be forwarded directly to the BIS indicated
in the NEXT_HOP entry.
2.) If the entry in the inter-domain FIB that
corresponds to the destination address of the
incoming IP packet contains a NEXT_HOP entry
that indicates a BIS that does not share a
subnetwork with the local BIS, then local BIS
has the following options.
a.) Encapsulate the IP packet
The local BIS may
encapsulate the IP
packet, using its own IP
address as the source
address and the IP
address of the next-hop
BIS as the destination
address.
b.) Use Paths Calculated by the
Intra-Domain Protocol
6
DRAFT RFC - IDRP for IP March 14, 1991
The local BIS may query
the intra-domain FIB to
ascertain if the intra-
domain protocol is aware
of a route to the
destination system.
Table 1) PICS Proforma for IDRP: IP packet forwarding
----------------------------------------------------------------
ITEM Questions/Features Refer. Status Support
IP_EXTFWD Does the BIS correctly forward 5.3 M Yes___
IP packets with destinations
outside its routing domain?
IP_INTFWD Does the BIS correctly forward 5.3 M Yes___
IP packets with destinations
inside its routing domain?
(The "ITEM" column describes the feature in the IP
forwarding function that the IDRP implementation is to
provide. The "Question/Feature" section seeks to
describe the feature. The Reference is the section in
this document that describes this feature. The status
gives an indication of "M" - Mandatory feature for an
IDRP implementation or "O" - optional feature. The
"Support" column is a column for the implementor to
check whether this feature is available in a particular
implementation.)
5.3) Domain Configuration Information
Correct Operation of IDRP described in ISO DIS ballot 10747
assumes that a minimum amount of information is available to both
the inter-domain and intra-domain routing protocols. This
information is static in nature, and is not expected to change
frequently. The specific format of this information is defined
in the RFC IDRP MIB document[9].
The information required by a BIS that implements the IDRP for IP
protocol is:
a.) Location and identify of adjacent Intra-Domain ISs (or
routers)
The MIB table INTRA-IS lists the IP addresses of the routers to
which the local BIS may deliver an inbound NPDU whose destination
lies within the BIS's routing domain. These routers listed in
the Intra-IS table support the intra-domain routing protocol of
7
DRAFT RFC - IDRP for IP March 14, 1991
this autonomous system, and lie within the same IP network (or
is this subnet?? -- Editor).
In particular if the BIS participates in both the inter-domain
routing protocol (IDRP), and the intra-domain routing protocol,
then the IP address of the local BIS will be listed in the INTRA-
IS table.
b.) Location and identity of BISs in BIS's domain
This information permits a BIS to identify all other BISs located
within its routing domain. This information is contained in the
MIB table INTERNAL-BIS, which contains a set of IP addresses
which identify the BISs in the domain.
c.) Location and identity of BISs in adjacent domains:
Each BIS needs information to identify the IP address of each BIS
located in an adjacent RD and reachable via a single subnetwork
hop. This information is contained in the IDRP MIB table
EXTERNAL-BIS-NEIGHBORS, which is a table of IP addresses.
d.) IP network address information for all systems in the routing
domain
This information is used by the BIS to construct its network
layer reachability information. This information is contained in
the MIB table INTERNAL-SYSTEMS. The IP network address
information can include:
- host addresses,
- Network and subnet mask sequences, or
- Supernetting Network sequences.
Please refer the IDRP MIB specification for the specific details
of the INTERNAL-SYSTEMS table.
The IDRP for IP protocol assumes the Supernetting approach
described in RFC XXX [10] to assignment and aggregation of IP
network reachability information. The IDRP for IP Usage document
[11] provides details on how to:
- carry IP information in the IDRP NLRI, and
- use the Supernetting approach to aggregate
IP network reachability information.
e.) LOCAL RDI
This information is contained in managed object LOCAL-RDI; it is
the RDI of the routing domain in which the BIS is located. As
specific in section 8 of this document, the RDI for an IDRP for
8
DRAFT RFC - IDRP for IP March 14, 1991
IP routing domain has an NSAP Address format. This NSAP Address
format is built out of a fixed "header" and the autonomous system
number of this autonomous system (routing domain).
f.) RIB-AttSet
The IDRP for IP BIS will eventually have to carry information
about what RIB-Attributes it supports. However, for this current
specification no RIB-Atts should be supported there for the RIB-
Atts table should contain simply the "null" set.
g.) RDC-Config:
This information identifies all the routeing domain
confederations (RDCs) to which the RD of the local BIS belongs,
and it describes the nesting relationships that are in force
between them. It is contained in the MIB table RDC-Config.
Each RDC is identified by an RDI which has the format described
in section 8 of this document.
h.) Local SNPAs
The LOCAL SNPA mib table contains a list of SNPAs per IP address
of the BIS.
5.4) Advertising NLRI information for IP addresses
The NLRI field in an UPDATE PDU contains IP address information
about systems that reside within a given routeing domain or whose
IP address space is under the control of the administrator of the
routing domain. It should not be used to convey information
about the operational status of these systems. The information
in the NLRI field is intended to convey static administrative
information rather than dynamic transient information: for
example it is not necessary to report that a given system has
changed from offline to online.
End systems (hosts) and Intermediate systems (routers) within a
RD using IDRP may use any IP address that is valid within IP
context. Within the NLRI, the address information for set of IP
addresses may be represented by an IP prefix. An IP prefix is
the sequence of bits in a 4 byte IP address which are common
between a set of IP addresses.
For example, the addresses 192.5.0.0 through 192.5.255.255 have
the
first 16 bits of the address information in common. These 16
bits of the IP address may be called an IP prefix which
represents the set of IP addresses 192.5.0.0 through
9
DRAFT RFC - IDRP for IP March 14, 1991
192.5.255.255.
An IP prefix must contain a contiguous set of bits, but the bits
may cover any part of the 4 byte IP address.
The following guidelines for inclusion of IP address prefixes in
the NLRI field of the UPDATE PDUs originated within a routing
domain will provide efficient use of this protocol:
a.) Only IP prefixes representing IP addresses that are within
the control of the Administrator of a given routeing
domain may be reported in the NLRI field for a RD.
These IP prefixes can represent IP addresses for
systems which are:
- online,
- offline, or
- allocated to the network, but not
to a machine yet.
b.) IP prefixes representing IP addresses outside of the RD
administrator's control shall not be included in the NLRI.
c.) For efficient use of the protocol, the WITHDRAW ROUTES
field should not be used to report the NLRI of systems
that are offline. This field should be used only to
advertise IP prefixes for IP addresses that are no
longer under the control of the administrator of the
local routeing domain, regardless of whether the
systems are online or offline.
6) IP address information in UPDATE message
The Network Layer Reachability Information field and the NEXT_HOP
attribute require IP addresses instead of NSAP address
information as specified by the IDRP. Both the NEXT_HOP
attribute and the NLRI start with a "Protocol-type" field. All
IP address information in the NLRI or NEXT_HOP will have the
protocol "Type" field is the NLPID of the protocol family which
for IP is XX as defined in ISO 95xx[12].
If the NEXT_HOP attribute has a "Protocol-type" field with a
NLPID other than the IP NLPID, the NEXT_HOP information should be
ignored. If the NLRI has a "Protocol-type" field with a NLPID
other than the IP NLPID, the NLRI information should be ignored.
NEXT_HOP information can either come from the NEXT_HOP attribute
or the packet header's source address from the IP packet that
carries the BISPDU.
10
DRAFT RFC - IDRP for IP March 14, 1991
7). Routing Domain Identifiers used for
both IP and OSI
Routing Domain Identifiers are numbers used in BISPDUs to
identify routing Domains in Routing Domain Pathway information.
The following attributes in IDRP require Routing Domain
information specified in terms of a Routing Domain Identifier:
1.) RD_PATH
2.) DIST_LIST_INCL
3.) DIST_LIST_EXCL
For ease of administration, the Routing Domain Identifier is
taken out of the NSAP address space. However, the Routing Domain
Identifier is just a number which identifies the Routing Domain,
and does not any relationship to any OSI addresses.
The Routing Domain Identifiers are simply numbers associated with
a Routing Domain. Therefore, an IP Routing Domain or IP and OSI
routing Domain can be identified with these numbers. An IP only
Routing Domain may generate a Routing Domain Identifier from by
using the following mapping:
47:00:05:80:ff:ff:00:00:00:DD:DD:aa:aa
Where aa:aa - are two hex bytes which encodes an AS value.
The 47:00:05:80:ff:ff:00:00:00:DD:DD is a fixed NSAP address
prefix which has been donated out the NSFNET AAI for IDRP over
IP. If a shorter "fixed NSAP address prefix" can be obtained out
of the GOSIP, ANSI or ICD space - this document will be
superseded by a document specifying the new shorter "fixed NSAP
address prefix" for these Internet RDIs.
Both Routing Domains and Routing Domain Confederations for the
Internet may be identified by this RDI. This Internet RDI
format is required in any domain which may inter-change inter-
autonomous system routing information with a router supporting
BGP.
If no exchange may occur with BGP within a domain or within the
Inter-Domain exchanges, any RDI may be used for IDRP for IP.
8.) Deployment Guidelines for IDRP for IP
The correct and efficient operation of the IDRP protocol requires
that certain guidelines are used for deployment with ISO routing
Domains. Some equivalent deployment guidelines for IDRP for IP
are required within Autonomous-systems. These guidelines
represent only the require deployment guidelines and not details
11
DRAFT RFC - IDRP for IP March 14, 1991
on the usage of IDRP for IP in the Internet. The details of the
Usage of IDRP for IP are contained in RFC xxx "Usage of IDRP for
IP"[11].
8.1) Minimum configuration of an AS/RD.
An autonomous system using IDRP must as a minimum contain:
- one BIS, and
- one BIS capable of delivering NPDUs to the
intra-domain routing function if the AS contains hosts
or end systems which on the same physical subnet
as the BIS.
8.2) One IP prefix per routing domain
Correct and efficient use of IDRP for IP protocol can only be
guaranteed if:
a.) An IP Prefix carried in the NLRI field of an UPDATE
PDU originated by a given RD should only be associated
with only one routeing domain: that is no system identified
by the prefix should reside in a different routeing domain.
Ambiguous routeing may result if several routeing domains
generate UPDATE PDUs whose NLRI fields contain identical
IP prefixes, since this would imply that the same system(s)
are simultaneously located in several routeing domains.
(Note: that routing domains may be multi-homed, but
not systems, subnets or networks within a routing domain
for IDRP for IP.)
b.) Several different IP prefixes may be associated with
a single routeing domain identifier (RDI).
8.3) Two BIS-BIS sessions between the same routers
An IP router may have many IP addresses, one for each interface.
An Intermediate system has only one Network Entity Title (network
address). An ISO IS may not have multiple sessions between BIS
since the NET of a router is uniquely identified. However, an IP
router may have multiple sessions between two IDRP for IP BISs
since each BIS may have multiple IP addresses. Two BIS may talk
to each other across two different subnets of the IP network.
Multiple connections between IDRP for IP BISs may not be
efficient but it not illegal nor does impact the robustness of
the IDRP for IP protocol.
12
DRAFT RFC - IDRP for IP March 14, 1991
13
DRAFT RFC - IDRP for IP March 14, 1991
9.) References
[1] ISO/IEC DIS ballot 10747 Information Processing Systems -
Telecommunications and Information Exchange between Systems -
Protocol for Exchange of Inter-domain Routeing Information among
Intermediate Systems to Support Forwarding of ISO 8473 PDUs.
[2] RFC xxx - (Sue Hares) Dual IDRP
[3] RFC xxx - (Sue Hares) IDRP Document Family Tree
[4] ISO/IEC IS 8473, Information Processing Systems, "Protocol
for Providing the Connectionless-mode Network Service and
Provision of Underlying Service". May, 1987.
[5] ISO/IEC IS 10589 - Information Processing Systems -
Telecommunications and Information Exchange between systems -
Intermediate System to Intermediate Intra-Domain Routeing
Information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service
(ISO 8473)
[6] ISO/IEC 9542 - Information Processing Systems -
Telecommunications and Information exchange between systems - End
systems to Intermediate system routeing exchange protocol for use
in conjunction with the Protocol for providing the
connectionless-mode network service (ISO 8473)
[7] RFC 791 (Jon Postel, editor) - Internet Protocol - DARPA
Internet Program Protocol Specification (September 1981)
[8] RFC xxx (Susan Hares) - IP Tos, Security and IDRP for IP
[9] RFC xxx (Susan Hares) - IDRP MIB
[10] RFC xxx (Vince Fuller and Tony Li) - Supernetting
[11] RFC xxx (Susan Hares) - Usage of IDRP for IP
[12] ISO/IEC 95xx - Definition of NLPID ????
(where NLPIDs are defined)
14
DRAFT RFC - IDRP for IP March 14, 1991
Table of Contents
Section Topic Page
==================================================
1 STATUS 2
2 Abstract 2
3 Introduction 2
4 Carrying IDRP packets over IP 4
5 Implementor's profile 4
5.1 Functions of IDRP protocol which
may not be implemented for
IDRP for IP 5
5.2 IDRP functions to forward IP
packets 5
5.3 Domain Configuration Information
Required for IDRP for IP 7
5.4 Advertising NLRI information for
IP addresses 9
6 IP Address information in UPDATE
BISPDU 10
7 RDIs in UPDATE BISPDU 10
8 Deployment Guidelines for
IDRP for IP 11
8.1 Minimum configuration of an AS/RD 11
8.2 One IP prefix per routing domain 11
8.3 Two BIS-BIS sessions between the 11
same routers
9 References 12
15